Security in computer systems and networks is an ongoing topic. Because system and OS level vulnerabilities are more difficult to exploit, the easier web application-layer has become the main focus of many hackers. For instance, sequential query language (SQL) injection and cross-site scripting (XSS) are considered as few of the top threats. The two security holes discussed above are often avoidable. For example, SQL injection can be prevented if the developers use prepared statements. Additionally, output escaping can effectively strengthen the web applications to defend them against XSS exploits, Microsoft™ has published security development lifecycle (SDL) to help developers on that mechanism.
Several tools and approaches are also available for finding risks in codes. IBM™ Rational™ Appscan™ performs dynamic application security testing by mimicking hacking web applications in order to find security holes. This tool operates on the codes that are built into executable components for the testing, and thus applies to runtime. Others use static code security analysis tools for finding unsafe code patterns (tainted execution flows) during application development, for example, using whitebox or graybox approaches to identify vulnerabilities through code analysis. These static analysis tools can be applied without the completion of building, for example, during the development. The tainted flow detection is relatively more accurate, but even with that, static analysis still cannot accurately judge whether there are existing sanitization processing in the execution flow and how effective it is. Those approaches still have limitations in accuracy, calling for the need for developers' review.
The typical practice observed today for secure development is: use static analysis and dynamic testing tool to find the vulnerabilities, and then generate security ticket into bug control systems such as IBM™ Rational™ ClearCase™ (CC) and IBM™ Rational™ ClearQuest™ (CQ), and let the programmers fix the codes and close the ticket; then wait until the testing phase, and perform the whole security analysis again to find holes.
There may be several limitations of the above practice. Conflict sanitization may exist along the tainted flow and the sanitization could be done in different phases (input phase, database (DB) access phase, or page display phase) to fix the security hole. Usually the responsible developers are not the same for different phases. Suppose two developers are both familiar with security and use HtmlEntity escaping to defend against XSS attacks. Then they may wrongly duplicate escaping—e.g. one escapes ‘<’ to ‘&lt;’ and the data is stored into DB, and later on the other developer retrieves the data from DB and further escapes ‘&lt;’ to ‘&amp; lt;’. Dynamic testing may find such cases but as mentioned above, it has to wait until code building.
As mentioned above, the hole location and the ideal sanitization codes are usually not co-located. For example, an SQL injection vulnerability happens when user input is directly used to concatenate an SQL query and to access a DB, but sometimes the sanitization location might be in the jsp page accepting the user's input. Therefore it is difficult for a reviewer to correlate the sanitization codes and the security ticket in CQ.
Similar vulnerability patterns occur regularly since rookie developers often may make the same mistakes again. Repeating to fix the similar holes results in the duplicate efforts. In addition, hole mitigation takes more time. For example, performing the security checks and hole mitigations in each testing iteration is less effective than doing it during the development. The latter can help developers judge it more accurately because developers have more knowledge about the structure of the code and the mitigation context. Further, the sanitization code may be changed due to some non-security reasons (method name, functionalities, etc), which means the vulnerability may reoccur, and re-examination of the hole is required.